Communications pricing and charging maintenance sub-system and process

ABSTRACT

Pricing and charging arrangements available to communication network operators or service providers take account of factors such as taxes which affect the billable value and which may be put in place in many different ways and at variable times in relation to data processing exercises which need to be carried out. A system is provided which can be used in generating bills by applying modifying factors which can be changed or added to in a relatively easy manner. An object-oriented front end for a legacy system can be used in design and subsequently embedded. Programs developed in an object oriented environment are converted into instructions implementable by a procedurally based processing device. An activity hierarchy of functions is created for each object, a data subject area is created for each object and a main calling program specifies the relationship between the programs and data areas so as to retain encapsulation of the original object oriented definition. This is particularly useful for developing new systems in an object oriented environment which may then be embedded into existing procedurally based systems.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation (under 35 USC §120/365) ofPCT/GB95/00732 designating the U.S. and filed Mar. 30, 1995 (nowabandoned) as, in turn, a continuation-in-part (under 35 USC §120/365)of U.S. application Ser. No. 08/253,739 filed Jun. 3, 1994 (nowabandoned).

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a data processing system for use inpricing and charging equipment and a production process therefor.

2. Related Art

The data processing system finds particular application incommunications systems, for identifying and/or adjusting amounts billedto a customer, based on charge-related values such as call duration, inrespect of additional factors such as taxes which are liable to besubject to change. It is becoming increasingly important, particularlyin the communications arena as communications systems grow ever moresophisticated, that factors involved in calculating billable amounts canbe both taken into account and updated even in complex billing systemswhich have to handle a wide variety of events and conditions.

The production process mentioned above provides a method of convertingprograms developed in an object oriented environment into instructionsimplementable by a procedurally based processing device.

Traditionally, large data processing systems were developed usingprocedural languages, such as COBOL and FORTRAN etc. Some of thesesystems are extremely large and are responsible for fundamentaloperational requirements of organisations, often essential to the corebusiness of said operations. Consequently, great care must be taken whensuch systems are modified. Furthermore, given the level of investmentmade in such systems, it is not practical to redevelop a whole systemwhen modifications are required.

Large systems of this type, often developed using techniques which havebeen superseded by improved development techniques, are often referredto as "legacy" systems or "heritage" systems, in which, were the systemto be produced today, different techniques would be employed so as toimprove reliability, robustness and the ability to implement amendmentsas changes in operating conditions occur. However, given that theseexisting systems often relate to very important aspects of an operationand represent a very large investment made by the operator, there isclearly a reluctance to make modifications unless these becomeabsolutely necessary.

Unfortunately, from an operator's point of view, modifications do becomenecessary, due to essential changes to the way in which the operation isperformed, possibly driven by changes in the laws or rules etc., underwhich the operation is performed. Under these circumstances, it istherefore necessary to implement changes to existing systems. However,such changes need to be implemented without affecting the rest of thesystem, thereby ensuring that the operation continues to function as awhole, secure in the knowledge that other aspects of the system will notbe impaired by the new amendments.

A further problem arises in that new instructions for the existingsystem must be consistent with the original instruction set, whichsuggests that modifications must be implemented using the techniquesavailable when the system was originally developed. This would thereforeresult in developers being constrained to use old fashioned techniquesinstead of being able to make use of modern developments. Furthermore,newly trained system developers would tend to be more familiar withmodern techniques, therefore, if forced to use previous techniques, suchdesigners would not benefit from their more modern skill, experience andexpertise.

Object oriented environments are known, an example of which is thatprovided by the Al International Corporation and licensed under theTrade Mark "Visual works" which includes the language "Smalltalk 80". Inan object oriented environment, data is encapsulated in functionality toprovide units of software known as objects. The data is then notdirectly accessible to entities external to the object. The objectoriented environment is developed by defining these objects and definingthe communications between them. Procedural environments in contrastprovide separate files for instructions and data. The transformation ofobject instructions into procedural instructions therefore consists of,amongst other things, collecting instructions from objects andcollecting data from objects and grouping these collections into fileswhich may be implemented within the procedural environment of theexisting system.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention, there is provideda data processing system, for use in pricing and charging equipment, toprocess data which has an associated set of modifying factors, byselecting and applying appropriately one or more of said modifyingfactors, the system comprising:

i) a data input, for data relating to one or more chargeable event(s)and containing for each event at least one charge-related value, such asduration, and at least one piece of additional data, such as event date;

ii) a process control module for controlling processing of said data;

iii) a first data store holding a set of definitions and a set ofidentifiers for said definitions, each definition including, directly orindirectly, at least one of said modifying factors and, associated witheach modifying factor, at least one condition such as date of validity;and

iv) a second data store arranged in sections allocated to respectivemodifying factors,

wherein, on receipt of data at the input, the process control moduleensures that the system determines a relevant identifier, accesses thefirst data store and locates the relevant definition for thatidentifier, sorts the data according to modifying factor, using saidadditional data and the relevant definition, and outputs thecharge-related values from the data to the sections of the second datastore, whereafter the system applies the allocated modifying factor(s)to the contents of the sections and outputs billable values thusgenerated.

Generally the system will be operating in a broader environment, such asthe billing and charging environment of a communications system, and,although the relevant identifier may be presented to the system in anumber of ways, in the broader environment it will already be associatedwith incoming data.

A data processing system according to the first aspect of the presentinvention provides a very flexible arrangement in terms of changes inmodifying factors. In particular, it allows charges arising before andafter a change in tax regime to be billed appropriately, even if thebill itself is only to be compiled at a later date. For instance, ifthere is a change in relevant tax rates on a particular communicationsservice, it is possible to accommodate that change, even if billing inarrears, by updating the definitions. In this case, the identifiersmight each identify a tax category and the definitions would set outdates on which that tax category was valid or on which the rate oftaxation for that category changed. A new class of tax can also be takeninto account simply by adding a new identifier and definition.

Alternatively, the identifiers may identify a product or service and thedefinitions then might set out relevant tax categories for the productsor services, and the date or dates on which the tax categories were orare effective. Again alternatively, the identifiers may identify a classof user and the definitions set out tax categories, and relevant datesof validity, for the classes of user.

The first data store may of course be divided to accommodate more thanone type of sets of identifiers and definitions, to be called uponappropriately by the data processing system, and this aspect gives thesystem particular flexibillity.

Using an object-oriented environment, whether or not in combination witha different type of environment, an embodiment of the present inventioncould be described as a process for generating billable amounts inrespect of data records for the supply of goods or services over aperiod of time, characterised by:

a period charge interface object, which provides control functionalityfor use by the process in relation to charges incurred by a user over aperiod of time;

a tax table object, defining tax rates and callable by said periodcharge interface object;

a tax calculation object for calculating tax values in respect of saidsupply of goods or services, callable by the period charge interfaceobject; and

an accumulation object, for accumulating values returned to the periodcharge object from the tax calculation object,

wherein, in use, input data including a period start date and a periodend date are supplied to the period charge interface object, tax ratesare supplied to the period charge interface object from the tax tableobject, a tax calculation is made by the tax calculation object, andresulting calculated tax values are supplied to the accumulation object.

It is possible to determine the functionality of an object by assigningit a set of alternative policies. The policies each may for instance setout a different algorithm which the object will apply. Part of thefunctionality of the object is to offer a user, or some other source ofinput, a choice between the policies. This is a particularly usefulapproach to use in embodiments of the present invention to achievedifferent outputs from the system. It also allows different options tobe built into the system at a later date, for instance by loadingdifferent types of table and updating the policies in the relevantobject providing control functionality.

According to a second aspect of the present invention, there is provideda method of converting programs developed in an object orientedenvironment into instructions implementable by a procedurally basedprocessing device, characterised by:

creating an activity hierarchy of functions for each of said objects;

creating a data subject area for each of said objects; and

defining a matrix of processes against data entities arranged to specifythe relationship between the object derived programs and the objectderived data subject areas to thereby retain the encapsulation definedby the object oriented program.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described by way of example only, withreference to the accompanying drawings, in which:

FIG. 1 schematically represents customer terminal equipment connected tointerconnected local exchanges and a central charging station;

FIG. 2 details processing equipment provided at the charging stationillustrated in FIG. 1, including a processor;

FIG. 3 identifies an overall procedure for modifying an existingprocedural system, in accordance with the present invention, comprisinga step of defining a system in an object oriented environment, a step ofvalidating the system defined in said environment, and a step ofconverting the object oriented system into a procedural language.

FIG. 4 details an overview of an object oriented system defined inaccordance with the procedure identified in FIG. 3;

FIG. 5 details part of the system shown in FIG. 4;

FIG. 6 details part of the system shown in FIG. 4;

FIG. 7 details part of the system shown in FIG. 4;

FIG. 8 details part of the system shown in FIG. 4;

FIG. 9 details part of the system shown in FIG. 4;

FIG. 10 details the function for calculating VAT rates given to VATexclusive amounts;

FIG. 11 is an expansion of the procedure shown in FIG. 10;

FIG. 12 details the procedure for calculating a rate determined at theend of a charging period;

FIG. 13 details the procedure when the rate is apportioned over aperiod;

FIG. 14 details the procedure when a charge is made on the basis mostfavourable to a customer; and

FIG. 15A and FIG. 15B detail the procedure identified at step 34 of FIG.3, for converting the objects oriented code into the form of aprocedural language.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

A schematic representation of customer terminal equipment 15 connectedto local exchange 16 is illustrated in FIG. 1. Each local exchangeincludes storage means 17 for collecting data relating to calls made bycustomers 15 connected to the associated local exchange 16.

If a customer initiates a call using terminal equipment 15A to callterminal equipment 15B, data is logged in the storage means 17 of localexchange 16 identifying the telephone number of the customer equipment15B. In addition, information may also be stored concerning the chargeband for customer equipment 15B, such as local, long distance orinternational etc. Furthermore, data is stored which identifies the wayin which the call was made which, for example, may state that the callwas made by the telephone number for terminal equipment 15B beingdialled directly on terminal equipment 15A. Alternatively, the callcould have been instigated with intervention from a manual operatorwhich, usually, would result in a higher rate of charge for the caller15A. It is also possible that, although terminal equipment 15A is beingused to make the call, it is being made by a customer who is actuallysigned up for terminal equipment 15C and, using charge card facilities,the cost of the charge is re-directed to the account associated withterminal equipment 15C, rather than the account associated with terminalequipment 15A.

Telephone bills are usually despatched to customers on a quarterly basisand the trend has been towards the despatching of bills from a centralcharging office, rather than from each individual local exchange orregional exchange etc. The advantage of despatching bills from a centraloffice is that, particularly with sophisticated systems which facilitatethe use of charge cards etc, it is possible to obtain information from aplurality of sources and bring it together for inclusion on a singlecustomer's bill. It is clearly advantageous from both the customerspoint of view and from the network providers point of view, given thatit is unnecessary to generate more than one account, with sophisticatedservices being added to conventional services and presented to thecustomer on a single account.

Thus, a central charging station 18 routinely polls each of the localexchanges 16 to obtain stored information relating to usage made byparticular customers. For the purpose of this example, it will beassumed that the time has come for the central charging station 18 togenerate a customer's account for the customer associated with theterminal equipment 15A. The charging station 18 may have already beensupplied with some of the information it requires, such as use of chargecards from other stations etc. It is now required to make a moreconventional investigation as to the normal-type telephone calls madeusing terminal equipment 15a. Thus, the charging station 18 "polls"storage device 17 at the local exchange 16 associated with the terminalequipment 15a. In response to a polling signal, storage device 17supplies the data stored therein relating to terminal equipment 15A tothe central charging station 18.

Clearly, it is essential from the network provider's point of view thatsophisticated handshaking and security provisions are made when thisinformation is transferred and many references are available as to howthis should be executed. However, suffice to say, for the purposes ofthe present disclosure, all of the relevant information is transferredfrom storage device 17 and the device 17 is effectively cleared so thatit may start afresh recording new usage made using terminal equipment15A, as part of the next charging period.

The charging station 18 includes a plurality of large mainframecomputers. Given the centralised nature of the system, the programsrunning on said computers are extremely large, therefore although it isdesirable or necessary to make modifications from time to time to theexisting system, extreme caution must be employed to ensure that theoverall operation of the system is maintained.

The present embodiment provides mechanisms by which modifications to theexisting procedural system at the central charging station 18 may beimplemented within an object oriented environment, thereby facilitatingsystem creation, system validation and system modification, beforeprocessing this information to produce instructions executable on theexisting system.

One of the functions performed by the central charging station 18 is thecalculation of value added tax (VAT). Previously systems were programmedin accordance with whatever VAT rules were appropriate at the time.Clearly, when modifications were made to the way in which VAT iscalculated, such as increases in the rate of VAT, the type of productsto which VAT applied and the specific way in which the VAT wascalculated, it was necessary to reformulate instructions compatible withthe existing system. The present embodiment allows instructions relatingto the generation of VAT amounts to be determined within an objectoriented environment and thereafter incorporated into the existingsystem.

The central charging station 18 shown in FIG. 1 is detailed in FIG. 2.The system includes a central processor 21, arranged to receive datarelating to customer usage from a main storage device 22, in addition toreceiving related data from a storage device 23. The processor 21 isalso arranged to supply data to and receive data from an archive storagearea 24 and, fundamentally, the processor 21 is arranged to supply printdata to accounts printing devices 25 which in turn produce paperaccounts for customers.

Non-conventional customer usage information is supplied to the main datastorage area 22 from remote storage area 26, arranged to receive detailsof charge card usage and of other sophisticated charging usage.Conventional charging usage, as previously described, is received fromstorage device 17 at the local exchanges via a polling device 27,arranged to contact each of the local exchanges, possibly usingfacilities provided within the network itself and to receive datatherefrom relating to usage for particular customers. Thus, under thecontrol of the main co-ordinating processor, not shown, it is determinedthat a statement of account is to be produced for a particular customer,resulting in data associated with that customer, in the form of thenumbers called, duration of call and means by which the call wasinitiated, being collected in a main data storage area 22.

In response to program control, processor 21 is arranged to analyse thedata stored in a main data storage area 22 and provide data which inturn may be supplied to the account printing device 25. Thus, it will beappreciated, that, in addition to calculating the actual charge for theservices provided, the processor 21 must also be capable of accuratelycalculating VAT, in order that said VAT amounts appear on the printedstatement of account.

The calculation of VAT in the United Kingdom is a good example of aprocedure which may require modification. Furthermore, during initialdevelopment work, it is difficult to anticipate all of the variationswhich may come in the not too distant future. However, if thesevariations are anticipated, measures may be taken to facilitateadjustment after the code has been embedded within the existing system.For this reason, it is appropriate to develop the code within anenvironment which facilitates validation exercises, allowing systemdesigners to test possibilities and, as far as possible, anticipatefuture requirements.

The overall procedure for modifying an existing procedural system isshown in FIG. 3. At step 32 a new sub-system is defined in an objectoriented environment. At the subsystem developed in the object orientedenvironment is validated. The validation exercise involves performingoperations in a similar fashion to that in which they would be performedwithin the fully operational system. Thus, whereas, in the operationalsystem information is supplied automatically from on-line sources,during the validation exercise at step 32, information may be suppliedmanually by means of a keyboard etc. The validation exercise allowsoperators to check that the procedures are being performed in thedesired manner. Furthermore, it also provides an environment where newideas may be tested and experience has shown that the development andanticipation of new procedures is very much an interactive procedure.Thus, given an off˜ line system upon which validation may be performed,an opportunity is provided for designers and operators to anticipatefuture demands and to thereby incorporate these options into the system.

Thus, a question is asked at step 33 as to whether all the designrequirements have been met. However it should be understood that thesedesign requirements include original design requirements, incorporatedinto the original system designed and implemented at step 31, inaddition to new design requirements which may have been establishedduring the validation procedure performed at step 32. If the questionasked at step 33 is answered in the negative, the system is re-designedat step 31 and a validation exercise is executed again at step 32.

Eventually, the question asked at step 33 will be answered in theaffirmative, whereafter a conversion procedure is implemented at step 34to convert the instructions developed within the object orientedenvironment into a procedural language. Thereafter, at step 35, theprocedural language developed at step 34 is embedded into the existingsystem, thereby allowing said system to operate in its updated form atstep 36.

The VAT processor is defined within an object oriented environment, inwhich the communication between objects is represented by the diagramshown in FIG. 4. The object oriented environment consists of a VAT TABLEobject 41 which in turn communicates with a TABLE MANAGER object 42.Further objects which communicate with the VAT TABLE object 41 are aRE-VAT object 43, a DE-VAT object 44, a PERIOD CHARGE VAT REFUND object45, a PERIOD CHARGE object 46 and a SINGLE DATE CHARGE object 47.Furthermore, queries are made to the VAT TABLE by means of a VALIDATEobject 48.

The accumulation of VAT amounts are made by means of an ACCUMULATORobject 49 and the ACCUMULATOR object 49 interfaces with externalcommands via an ACCUMULATE object 50. The ACCUMULATE object 50 alsocommunicates with a BASIC VAT CALCULATION object 51, which in turn alsocommunicates with the DE-VAT object 44, the RE-VAT object 43, the PERIODCHARGE VAT REFUND object 45 and the PERIOD CHARGE object 46.Calculations made by the BASIC VAT CALCULATION object 51 may requirerounding, therefore the object communicates with a ROUNDER object 52.

The ACCUMULATOR object 49 communicates with the PERIOD CHARGE object 46and the SINGLE DATE CHARGE object 47. The PERIOD CHARGE VAT REFUNDobject 45 communicates with the RE-VAT object 43 and the PERIOD CHARGEobject 46, in addition to communicating with the BASIC VAT CALCULATIONobject 51. A CONFIGURATION MANAGER object 53 communicates with theROUNDER object 52, the PERIOD CHARGE object 46 and the SINGLE DATECHARGE object 47.

Many of the objects communicate with an operator, which are referred toas external type objects, including the CONFIGURATION MANAGER object 53,the TABLE MANAGER object 42, the VALIDATE object 48, the DE-VAT object44, the RE-VAT object 43, the ACCUMULATE object 50, the PERIOD CHARGEVAT REFUND object 45, the PERIOD CHARGE object 46 and the SINGLE DATECHARGE object 47. Note, different operators would access differentinterfaces when performing different functions.

Thus, within the object oriented environment, a distinction is madebetween interfacing external objects and internal objects. When embeddedwithin the existing procedural system, interfacing external objects willprovide interfaces to other modules within the system, which may wish touse the services of the processor detailed in FIG. 4. Internal objectssupport the interface objects and maintain the main attributes of theVAT processor, that is to say, the VAT table, the product table, thecustomer table, the pair table and the accumulator table. In addition,the internal objects also provide the interface objects with therequired processing capacity for accumulating charges, calculating VATcharges and performing VAT validation.

Thus, the outer ring 54 shown in FIG. 4 models the VAT processor. Thecircles model the objects contained within it; interface objects areconnected to the outer ring 54, internal objects are only connected toother objects and an arrow is drawn from one object to another when anobject accesses another in order to perform a particular task.

The VAT processor maintains five tables, the VAT table, the producttable, the customer table, the pair table and the accumulator table. Thefirst four tables are maintained in the VAT TABLE internal object, whilethe accumulator table is held by the ACCUMULATOR internal object.

The VAT table lists all existing VAT categories together with the ratesthat apply to them on the first date for which they were valid, alongwith any subsequent changes to their rates. For each category a list ismaintained of associations, listing the initial date and the rate andany subsequent dates on which their rate is changed, with a new ratethat applies from those dates. These elements are placed in such a listin date order. An example of a VAT table is as follows:

    ______________________________________                                        VAT TABLE                                                                     ______________________________________                                        S              <(1/1/91,15),(1/4/91,17 5)>                                    P              <(1/1/91,0),(1/4/91,15)>                                       M              <(1/1/91,0),(1/3/92,10)>                                       U              <(1/1/91,6)>                                                   ______________________________________                                    

This table contains four VAT categories, identified as S, P, M and U.The first element of the list associated with a VAT category indicateswhen that VAT category was first valid. For example, VAT category S wasvalid from Jan. 1, 1991, when the VAT rate at that date was fifteenpercent. The next element of the list for category S indicates that theVAT rate applicable to category S was changed to seventeen point fivepercent on Apr. 1, 1991. Hence, the rate of fifteen percent applied to Son any date from Jan. 1, 1991 up to and including Mar. 31, 1991.

It is possible to add a new VAT category, resulting in a new elementbeing added to the VAT table. This element contains the name of the newcategory and a list of associations (date followed by the rate).

Procedures are implemented within the system to check whether aparticular VAT category is valid. A VAT category is valid on aparticular date if a VAT category is used in the VAT table and if avalid rate is associated with the entry. For example, VAT category P maybe considered as being valid on Jan. 1, 1991 but said category was notvalid on Dec. 31, 1990. A VAT category is valid over a given period ifit is used in the VAT table and if a valid rate is associated with a VATcategory for each date covered by this period. Periods are described bytheir start date and end date and a VAT category is valid over a periodif it is valid for each date of said period from its start date and isincluded up to its end date.

The product table, customer table and pair table relate to productcodes, customer classifications and their combinations to VAT categoriesand the dates from which these VAT categories apply. These three tablesare organised to hold a series of keys and they link each of these keysa list of associations identifying the date and VAT category. The keysused in the product table are product codes and the keys used in thecustomer table are customer classifications, whereas the keys used inthe pair table are combinations of product codes and customerclassification.

For each key, the tables will maintain a list of associations(identifying date and VAT category) listing the first date on which thekey was valid and the VAT category that applied from that date, followedby any subsequent dates on which the associated VAT category changed,with a new category that applied from those dates. The elements in thelist are in date order.

The product table, customer table and pair table are similar in styleand only differ in the type of keys that are used. They are interpretedand changed in similar ways and the entries may be used to performvalidation checks. An example of a product table is as follows:

    ______________________________________                                        PRODUCT TABLE                                                                 ______________________________________                                        phone            <(1/1/93, S)>                                                fax              <(1/1/93, S)>                                                pager            <(1/5/93/ S),(1/7/93, P)>                                    ______________________________________                                    

The first element of the list associated with a product code identifieswhen that product was first valid. For example, product code "phone" wasvalid from Jan. 1, 1993. The VAT category that applied to product"phone" on that date was S. Product code "pager" was first valid on May1, 1993 under VAT category S. The next element of the list for "pager"indicates that the VAT category applicable to "pager" was changed to Pon Jul. 1, 1993. Hence, the category S applied to pagers on any datefrom May 1, 1993 up to and including Jun. 30, 1993.

An example of a customer table is as follows:

    ______________________________________                                        CUSTOMER TABLE                                                                ______________________________________                                               OAP          <(1/1/93, S)>                                                    business     <(1/4/93, P)>                                             ______________________________________                                    

This table contains two customer classifications, namely "Old AgePensioner" and "Business". It is interpreted like the product tableidentified above, that is to say, the first element of the listassociated with a customer classification identifies when that productwas first valid. Subsequent elements list changes to the applicable VATcategory and the dates on which those changes took effect.

An example of a pair table is as follows:

    ______________________________________                                        PAIR TABLE                                                                    ______________________________________                                        phone x OAP          <(1/1/93, S)>                                            phone x business     <(1/7/93, U)>                                            ______________________________________                                    

It is interpreted in a substantially similar way to the product tableidentified above.

The ACCUMULATOR object holds the accumulation of single date charges andperiod charges. Each information item consists of a VAT rate and a VATexclusive amount and the accumulator table holds the information items.

The following table is an example of an accumulator table:

    ______________________________________                                        ACCUMULATOR TABLE                                                                    Vat Rate                                                                             excl. amount                                                    ______________________________________                                               15.00  87.72                                                                  17.50  199.83                                                                 00.00  65.00                                                           ______________________________________                                    

In order to accumulate a VAT exclusive amount, it is added to the VATexclusive amount of the information item in the accumulated table and isassociated with a rate that applies to the given amount. If no suchinformation item exists in the accumulated table, a new information itemis added to the table. This item associates the VAT exclusive amountthat is to be accumulated with the rate that applies to it. Thus, it canbe appreciated that the re-setting of the accumulator table effectivelyremoves all numerical data stored therein. VAT rates are created as anitem when they are required and thereafter VAT exclusive amounts areaccumulated within the associated item.

The system can be used for four distinct operations. Firstly, it can beused to perform a charging operation used to prepare a customer's bill,involving the working out of VAT amounts. Secondly, the system can beused to process receipts, from customers. Thirdly, the system can beused for a general enquiry made by operators when information isrequired concerning VAT amounts, and fourthly, the system is designedsuch that rconfigurations may be made, particularly when changes occurto the way in which VAT is calculated.

All of the objects detailed in FIG. 4 are not necessarily employed foreach of the above defined operations. The four operations will thereforebe described with reference to specific drawings, in which the objectsactually employed within the system defined in FIG. 4 are repeated inFIGS. 5 to 8, although it should be appreciated that the objectsidentified in FIG. 5 to 8 are identical and form part of the structuredefined in FIG. 4.

FIG. 5 details the operations performed during the charging process,that is to say, when a customer's bill is being made up.

A typical procedure for bill production for a particular customer willbe for access to the system being provided via the ACCUMULATE object 50.

Communication task 61 represents an operation performed by theACCUMULATE object 50 so as to reset the value stored by the ACCUMULATORobject 49.

Thus, input data will consist of any chargeable item for which it isnecessary to calculate VAT before this item may be added to a billalthough, it should be appreciated, that some items may be zero rated orexempt from VAT and this will be taken into account during the VATprocessing procedure.

VAT may be accumulated in two specific ways. Firstly, VAT may beincurred on a transaction which takes place at a particular point intime and is therefore processed as a single date charge. Alternatively,VAT is also incurred through services which are provided over a periodof time and are therefore processed as a period charge. It is importantto separate single date transactions from period charges primarilybecause it is possible that the VAT rate may change over the periodunder consideration.

In order to calculate VAT for an item for which a transaction hasoccurred on a particular date, access is provided to the SINGLE DATECHARGE object was incurred. In accordance with Policies specified withinthe SINGLE DATE CHARGE object 47, a call is made to the VAT table 41,illustrated by task 62, which in turn returns a VAT rate to the SINGLEDATE CHARGE object 47. After receiving the appropriate VAT rate from theVAT TABLE object 41, the amount, exclusive of VAT, is supplied to theACCUMULATOR object 49. The ACCUMULATOR object 49 includes a plurality ofaccumulators, each associated with a particular VAT rate. Thus, the VATexclusive amount supplied to the ACCUMULATOR object 49, via the taskidentified as 63, also includes an identification of the applicable VATrate, such that the ACCUMULATOR object 49 accumulates the VAT exclusiveamount in the accumulation area specified for the particular VAT amountsupplied from the SINGLE DATE CHARGE object 47.

In some circumstances, it may be necessary for the SINGLE DATE CHARGEobject 47 to make more than one call to the VAT TABLE object 41. Forexample, it may be possible to base VAT on the date on which thetransaction occurred or, alternatively, it is possible to base VAT onthe date of the bill. A further coniplication arises if the policy isselected in response to some other variable.

The PERIOD CHARGE object 46 is similar to the SINGLE DATE CHARGE object47, although it is capable of processing charges which occur over aperiod of time. The way in which period charges are actually calculatedis again a matter of policy and many variations are possible. Thus, inaccordance with the selected policy, it is possible to base VAT chargesover a period on the start date, the end date, either of these inresponse to another variable or, in a more sophisticated environment, tohave VAT amounts apportioned over the period concerned. When theapportionment policy is in operation, it is necessary for the PERIODCHARGE object 46 to supply a start date and an end date via a taskindicated as 64 to the VAT TABLE object 41. The VAT TABLE object 41 isthen arranged to apportion the VAT exclusive amount over the periodconcerned and to identify the VAT rate applicable to the apportionedamounts. Thus, the VAT exclusive amounts are then accumulated in theACCUMULATOR object 49 via task 65, in accordance with the VAT ratessupplied by the VAT TABLE object 41.

The BASIC VAT CALCULATION object 51 is essentially provided to calculatethe final VAT amounts. However, under some situations, it may benecessary to calculate actual VAT amounts in order to determine which ofa plurality of possible algorithms is to be selected. Thus, it ispossible for the PERIOD CHARGE object 46 to supply data over line 66 tothe BASIC VAT CALCULATION object 51 which in turn returns VAT amounts tothe PERIOD CHARGE object 46, allowing it to make decisions as to whichis the preferred algorithm.

When all of the relevant data has been supplied to the system, anindication is made via the ACCUMULATE object 50 to the effect that theVAT amounts are to be calculated. The ACCUMULATE object 50 makes a callto the ACCUMULATOR object 49, via task line 67, effectively enquiring asto the status of the ACCUMULATOR object at that point in time. Thus, inresponse to this enquiry, data accumulated in the ACCUMULATOR object 49is supplied back to the ACCUMULATE object 50 which in turn supplies thisinformation, via task 68, to the BASIC VAT CALCULATION object 51. Thus,in response to this data, supplied from the ACCUMULATE object 50, theBASIC VAT CALCULATOR object 51 determines VAT amounts from the VATexclusive amounts and tne VAT rates stored in the ACCUMULATOR object 49.A special case arises concerning items which are VAT exempt or have aVAT rate of zero, to ensure that the BASIC VAT CALCULATION object doesnot multiply VAT exempt amounts by zero. Actual VAT amounts calculatedby the BASIC VAT CALCULATOR object 51 are supplied to the ROUNDER object52 identified as task 69, which rounds these values in accordance withcurrent policy. Thus, for example, all VAT amounts generated by thebasic VAT calculator may be truncated to a predetermined number ofdecimal places, thus these truncated values would then be supplied backto the BASIC VAT CALCULATOR object 51. Thereafter, the VAT amounts arereturned back to the ACCUMULATE object 50.

Under some circumstances it may be necessary to give a customer a VATrefund. In particular, this occurs when a service has been paid for inadvance and the VAT rate for that particular service has been reducedover the period concerned. Under these circumstances, an operatorsupplies data to the PERIOD CHARGE VAT REFUND object 45, which is anobject configured so as to inherit all the functionality of the PERIODCHARGE object 46. The first operation performed by the PERIOD CHARGE VATREFUND object 45 is to calculate the value of VAT previously charged, bycalling the RE-VAT object 43, identified as task 70. The data suppliedto the RE-VAT object 43 comprises a VAT exclusive amount and a VATcategory or a customer or service classification. The RE-VAT object 43makes a call to the VAT TABLE object 41 via task 71 which in turnreturns the appropriate VAT rate for the item under consideration. Thisinformation is then supplied from the RE-VAT object 43 to the BASIC VATCALCULATION object 51 via task 72, which in turn returns the associatedVAT amount. This value is then returned to the PERIOD CHARGE VAT REFUNDobject 45. Subject to appropriate policy definitions being stored withinthe PERIOD CHARGE VAT REFUND object 45, a further call is made by saidobject 45 to the VAT TABLE object 41 via task 73, in order to determinethe VAT rate which would be charged at the present time. Again, thisinformation is then relayed to the BASIC VAT CALCULATION object 51 toreturn the actual VAT amount. A comparison is then made of the VAT whichwas charged with the VAT which would be charged at the present time andif the new value is lower than the actual value charged, details of anappropriate refund are returned to the operator.

The description above relates to the generation of bills which includeVAT amounts. The system is also configured to take account of VATtransactions when payments are made. In particular, it is possible forpayments to be made without making specific reference to a particularbill. Under these circumstances, it is not immediately apparent as towhat proportion of the bill relates to an actual charge and whatproportion relates to VAT payable to Customs & Excise. Thus, under thesecircumstances, it is necessary to divide a total amount into the non-VATamount and the VAT amount. In dealing with receipts, it is alsosometimes necessary to calculate a VAT amount from a VAT exclusiveamount. Procedures for implementing such actions are shown in FIG. 6. Ifan operator has an amount which is inclusive of VAT and it is desired toobtain the value exclusive of VAT, an input is supplied to the DE-VATobject 44. A call is then made, identified by task 81, to the VAT TABLEobject 41. The DE-VAT object 44 supplies information identifying the taxpoint date and the classification, whereupon the VAT TABLE object 41returns the VAT rate applicable to that transaction. This information isthen supplied to the BASIC VAT CALCULATION object 51 via task 82. Inresponse to this call, the BASIC VAT CALCULATION object 51 returns theVAT exclusive amount and the amount of VAT paid. These values arecalculated with a call, where appropriate, to the ROUNDER object 52 viatask 85. Thus, the DE-VAT object 44 has received a VAT rate from the VATTABLE object 41, and the VAT exclusive rate and the VAT amount from theBASIC VAT CALCULATOR object 51. This information is now returned to theoperator via the interface identified as 86.

In addition to calculating VAT exclusive values from inclusive values,operators dealing with receipts can also re-calculate VAT when given aVAT exclusive value. The VAT exclusive value, along with details of thedate of the transaction and the transaction type result in a call overinterface 87 to the RE-VAT object 43. The RE-VAT object 43 makes a call,via task 83, to the VAT TABLE object 41, which in turn returns theappropriate VAT rate. The RE-VAT object 43 then calls the BASIC VATCALCULATION object 51, identified by task 84, which in turn returns theVAT amount. Thus, the RE-VAT object 43 returns over interface 87, theVAT rate, the VAT amount and the VAT inclusive value.

In addition to generating VAT bills and processing receipts, generalenquiries may be made to access the information stored in the VAT tableas illustrated in FIG. 7. A VAT TABLE enquiry results in a call to theVALIDATE object 48 via an interface 91. In response to the enquiry madeto the VALIDATE object 48, a call is made to the VAT TABLE object 41 andthe appropriate information is returned to the VALIDATE object 48,whereafter it is relayed over the interface 91 to the operator.

An advantage of the present embodiment is that it is configured suchthat amendments can be made to the way in which VAT calculations areexecuted. In particular, it is possible to update the VAT TABLE object41, and make modifications to the ROUNDER object 52, the PERIOD CHARGEobject 46 and the SINGLE DATE CHARGE object 47.

As shown in FIG. 8, modifications to the VAT TABLE object 41 are madevia the TABLE MANAGER object 42. An operator is given access to theTABLE MANAGER object 42 via an interface 93 and updates for the VATTABLE are thereafter supplied from the TABLE MANAGER object 42 over alink 94 to the VAT TABLE object 41.

Similarly, as shown in FIG. 9, an interface 95 to the CONFIGURATIONMANAGER object 53 facilitates modifications being made to the ROUNDERobject 52 via a link 96, the PERIOD CHARGE object 46 via a link 97 andthe SINGLE DATE CHARGE object 47 via a link 98.

The individual objects within the object oriented environment will nowbe considered in detail.

TABLE MANAGER

The table manager 42 controls configuration operations relating thechanging of entries in the VAT table and the product table.

A first function performed by the table manager adds a given VATcategory to the VAT table, with the given VAT rate to apply from thegiven date. If the given VAT category is already used in the VAT table,an appropriate message is returned and the VAT table is left unchanged.

A second function adds a given product code to the product table, withthe given VAT category, to apply from the given date. If the givenproduct code is already used in the product table, an appropriatemessage is returned and the product table is left unchanged.

A third function adds a given customer classification to the producttable, with a given VAT category to apply from the given date. If agiven customer classification is already used in the customer table, anappropriate message is returned and the customer table is leftunchanged.

A fourth function adds the given combination of product code andcustomer classification to the pair table, with a given VAT category toapply from the given date. Again, if the given combination is alreadyused in the pair table, an appropriate message is returned and the pairtable is left unchanged.

A fifth function changes the VAT table to indicate that the given VATrate will be the new VAT rate to apply to the given VAT category fromthe given date. If the given VAT category is not used in the VAT table,an appropriate message is returned and the VAT table is left unchanged.

A sixth function changes the product table to indicate that the givenVAT category will be the new VAT category to apply to the given productcode from the given date. If the given product code is not used in theproduct table, an appropriate message is returned and the product tableis left unchanged.

A seventh function changes the customer table to indicate that the givenVAT category will be the new VAT category to apply to the given customerclassification from the given date. If the given customer classificationis not used in the customer table, an appropriate message is returnedand the customer table is left unchanged.

An eighth function changes the pair table to indicate that the given VATcategory will be the new VAT category to apply to the given combinationof product code and customer classification from the given date. If thegiven combination is not used in the pair table, an appropriate messageis returned and the pair table is left unchanged.

A ninth function changes the VAT table to indicate that the given VATcategory is no longer valid from the given date. If the given VATcategory is not used in the VAT table, an appropriate message isreturned and the VAT table is left unchanged.

A tenth function changes the product table to indicate that the givenproduct code is no longer valid from the given date. If the givenproduct code is not used in the product table, an appropriate message isreturned and the product table is left unchanged.

An eleventh function changes the customer table to indicate that thegiven customer classification is no longer valid from the given date. Ifa customer classification is not used in the customer table, anappropriate message is returned and the customer table is leftunchanged.

A twelfth function changes the pair table to indicate that the givencombination of product code and customer classification are no longervalid from the given date. If the given combination is not used in thepair table, an appropriate message is returned and the pair table isleft unchanged.

RE-VAT

The RE-VAT object controls operations requested by receipts when it isnecessary to re-calculate a VAT amount.

A first function calculates the VAT amount that applies to the given netamount on the given date for the given VAT category. This VAT amount isreturned, together with the gross amount and the VAT rate which appliesto that given amount.

A second function calculates the VAT amount that applies to the givennet amount on the given date for the given product code. The functionreturns this VAT amount, together with the gross amount and the VAT ratethat applies to that amount.

A third function calculates the VAT amount that applies to the given netamount on the given date for the given customer classification. Thefunction returns this VAT amount, together with the gross amount and theVAT rate that applies to the given amount.

A fourth function calculates the VAT amount that applies to the givennet amount on the given date for the given combination of product codeand customer classification. The function returns this VAT amounttogether with the gross amount and the VAT rate that applies to thegiven amount.

DE-VAT

This object controls operations requested by receipts concerning theremoval of VAT amounts, referred to herein as DE-VATING.

A first function calculates the VAT amount and the net amount thattogether form a given gross amount, using the given VAT category anddate. The function returns the VAT amount and the net amount and the VATrate that applies to the given amount.

A second function calculates the VAT amount and the net amount thattogether form the given gross amount, using the given product code anddate. The function returns the VAT amount and the net amount and the VATrate that applies to the given amount.

A third function calculates the VAT amount and the net amount thattogether form the given gross amount, using the given customerclassification and date. The function returns the VAT amount and the netamount and the VAT rate that applies to the given amount.

A fourth function calculates the VAT amount and the net amount thattogether form a given gross amount, using the given combination ofproduct code, customer classification and date. The function returns theVAT amount and the net amount and the VAT rate that applies to the givenamount.

PERIOD CHARGE VAT REFUND

The PERIOD CHARGE VAT REFUND object 45 controls operations requested bybilling operators concerned with calculating refunds applicable toperiod charges that have been paid for in advance but to which different(usually smaller) VAT amounts would apply had they been charged afterthe period, on the current bill.

The functions available within this object first of all calculate theVAT amount that was originally charged. Next, the VAT amount iscalculated that would apply to the period charge if it had been includedon the current bill. These two charges are compared and if theoriginally charged VAT amount is larger than the VAT amount applicableon the current bill date, the difference between the amounts isreturned. This is the VAT refund that is applicable to this periodcharge. If the original VAT amount is less than the new VAT amount, azero is returned, indicating that no VAT needs to be refunded. If,however, there is no valid rate associated with this amount on the givenoriginal tax date , an appropriate message is returned instead.

A first function calculates a VAT refund for a period charge that hasbeen paid for in advance but which may have attracted a different(smaller) amount of VAT had it been charged at the rate applicable forthe period of the current bill. If, however, there is no valid rateassociated with this amount on the original tax date, an appropriatemessage is returned.

A second function implements a similar procedure but related to aproduct code, while a third is related to a customer code and a fourthis related to a product-customer combination.

PERIOD CHARGE

The PERIOD CHARGE object 45 controls operations requested by billingoperators concerned with the accumulation of period charges.

A first function calculates the VAT rates that apply to the given VATexclusive amounts, using the given VAT category, period start date andperiod end date, following the current favor policy. The functionaccumulates the VAT exclusive amount in the accumulated table at theappropriate rates.

A second function calculates the VAT rates that apply to the given VATexclusive amounts, using the given product code, period start date andperiod end date following the current favor policy. The functionaccumulates the VAT exclusive amount in the accumulator table at theappropriate rates.

This second function is detailed in FIG. 10. The function is initiatedat step 201 and at step 202 an input is received which identifies theVAT exclusive amount, the product code, the period start date and theperiod end date. At step 203 a bill date is set to the current date,given that this is the date on which the bill is being calculated.

At step 204 an enquiry is made to the VAT table to check whether theinput data received at step 202 is valid. Thus, a question is asked atstep 205 as to whether the data was valid and if this question isanswered in the negative, an output error is generated at step 206 andthe process terminates at step 217. If the question asked at step 205 isanswered in the affirmative, an enquiry is made at step 208 as to thestatus of the current policy, which may be answered in four possibleways. Firstly, the policy may set that over a period charge the VAT iscalculated with respect to the bill date. Secondly, VAT could becalculated with respect to the end date of the period underconsideration. Thirdly, the VAT could be apportioned over the period ofconsideration or fourthly, the VAT could be charged at a rate selectedin response to another variable.

Referring to FIG. 11, the procedures carried out in response to thefirst selected policy, that is to say, VAT is charged with respect tothe bill date (if yes at 209, otherwise, go to step 211), is initiatedat step 300 entered via block 210 of FIG. 10. At step 301 the VAT rateis obtained from the VAT table. A check is then made as to whether theproduct code is valid at the bill date. Thus, a question is asked atstep 303 as to whether the product code is valid and if this question isanswered in the negative the appropriate VAT amount is selected from theVAT table at step 304, based upon the end date. Thus, at step 305 VAT iscalculated with reference to the rate at the end date and the process isterminated at step 308 by return to block 216 of FIG. 10.

If the question asked at step 303 is answered in the affirmative, therate determined at the bill date is implemented at 307 in order tocalculate the VAT amount whereafter the process terminates at step 308.

Referring to FIG. 12, the procedures performed in response to the secondpolicy option at step 211, that is to say, that the VAT rate is thatdetermined at the end of the period, is initiated at step 400 enteredvia 212 (if yes at 211, otherwise, go to 213). At step 401 the rate isobtained from the VAT table, applicable at the end of the period underconsideration. Thereafter, the amount and rate is accumulated at step402 and the process terminates at step 403.

Referring to FIG. 13, the procedures implemented in response to thethird policy option at step 213, that is to say, the VAT rate isapportioned over the period, is detailed at step 500 entered via block214 of FIG. 10 (if yes at 213, otherwise, go to 215).

At step 501 a function (or routine) is called, which returns with a listof amounts and the rates which apply to them. These amounts arethereafter accumulated at step 502 and the process terminates at step503.

Referring to FIG. 14, the procedures for the fourth policy option atstep 213, that is that none of the three preceding policies applies, aredetailed from step 600 entered via block 215 of FIG. 10. At step 601 acall is made to a function which returns a list of amounts and rateswhich apply to them. At step 602 each of the possible amounts and ratesare supplied to the BASIC VAT CALCULATION object 51 which in turnreturns VAT amounts. The amounts returned from the VAT CALCULATIONobject are summed for subsequent comparison.

Having determined the VAT amounts applicable over a period, other meansby which the VAT could be calculated are determined, in order that thesemay be compared. Thus, at step 603 the VAT rate applicable at the enddate is obtained from the VAT table, whereafter, at step 604, the rateread from said table at step 603 along with the exclusive amount issupplied to the basic VAT calculation object to obtain the amount of VATapplicable based upon the end date.

Step 605 initiates the calculation of VAT applicable at the bill date.At this step, the VAT rate applicable at the bill date is read from theVAT table and a question is then asked at step 606 as to whether thecategory is valid at the date of the bill. If this question is answeredin the negative, the selected mode of billing is taken from the othertwo options available within this procedure. Thus, a question is askedat step 607 as to whether the sum derived a step 602 is less than theamount derived at step 604. If this question is answered in thenegative, meaning that the amount derived at step 604 is the smaller andis therefore the amount to be charged to the customer, an accumulationis made of the exclusive amount at step 608, along with an indication ofthe rate applicable at the end date. Thereafter, the procedureterminates at step 609. Alternatively, if the question asked at step 607is answered in the affirmative, to the effect that the sum derived atstep 602 is less than the amount derived at step 604, the list derivedat step 601 is accumulated at 610 and the procedure terminates at step609.

Alternatively, the question asked at step 606 may be answered in theaffirmative, to the effect that the code identified at step 605 isvalid. Consequently, at step 611 the amount and rate applicable at thebill date are sent to the basic VAT calculator to determine the VATamount. Thereafter, at step 612 a comparison is made of the sumcalculated at step 602 and the amounts derived from step 611.

If the question asked at step 612 is answered in the affirmative, to theeffect that the amount calculated at step 602 is the smaller, the listof values returned at step 601 are accumulated at 613 and control isdirected to step 609. If, however, the question asked at step 612 isanswered in the negative, control is directed to step 614.

At step 614 a question is asked as to whether the amount calculated atstep 604 is smaller than the values determined at step 611. If thisquestion is answered in the affirmative, control is directed to step615, whereupon the amount of VAT applicable at the end date isaccumulated. Alternatively, if the question asked at step 614 isanswered in the negative, the amount applicable at the bill date isaccumulated at step 616. After both steps 615 and 616, control isdirected to step 609.

SINGLE DATE CHARGE

The SINGLE DATE CHARGE object 47 controls requests by billing operatorsconcerned with accumulating single date charges. A total of eightfunctions are available within the object.

For the first four functions, a VAT exclusive amount is stored in theaccumulator table. The given amount must be a positive or zero amountand relates to a debit for a single charge related to a purchase on thegiven charge date. If, however, there is no valid rate associated withthis single date charge following the current favor policy, no amount isaccumulated and an appropriate message is returned.

If the current favor policy is to calculate VAT in relation to the dateon which the transaction took place, the given amount is accumulated atthe VAT rate that applied to the charge on the given charge date.Alternatively, if the current favor policy specifies that VAT iscalculated at the bill date, the amount is accumulated at the VAT rateapplicable to the charge on the date of the current bill. If there is novalid rate associated with the charge on the current bill date, theamount is accumulated at the rate that applied on the given charge date.

If the current favor policy is such as to make a charge in dependenceupon another variable the amount is accumulated on either the bill dateor the charge date, dependent upon said variable.

A first function calculates the VAT rate that applies to the given VATexclusive amount, using the given VAT category and charge date,following the current favor policy. The function accumulates the VATexclusive amount in the accumulator table at the appropriate rate.

A second function calculates the VAT rate that applies to the given VATexclusive amount, using the given product code and the charge date,following the current favor policy. The function accumulates the VATexclusive amount in the accumulator table at the appropriate rate.

A third function calculates the VAT rate that applies to the given VATexclusive amount, using the given customer classification and chargedate, following the current favor policy. The function accumulates theVAT exclusive amount in the accumulator table at the appropriate rate.

A fourth function calculates the VAT rate that applies to the given VATexclusive amount, using the given combination of product code andcustomer classification and the given charge date, following the currentfavor policy. The function accumulates the VAT exclusive amount in theaccumulator table at the appropriate rate.

Functions 5 to 8 store a given VAT exclusive amount, which is a VATcredit, in the accumulator table. The given amount must be a negative orzero amount and relates to a credit for a single charge that was chargedearlier on a bill issued on the given original bill date. If, however,there is no valid rate associated with a single date credit, followingthe current favor policy, no amount is accumulated and an appropriatemessage is returned.

Should legislation change, resulting in a change of the current favorpolicy to "charge at the date of the transaction", the functioncalculates the option which would have yielded the highest VAT amountapplicable at the date of charge, had it been applied on the givenoriginal bill date. The credit is accumulated in the accumulator as ifit were applied on the given original bill date.

Again, should legislation change, resulting in a change of the currentfavor policy to "calculate charges in relation to the date of the bill",the given amount is accumulated at the VAT rate that applied to thecredit on the current bill date. If there is no valid rate associatedwith the charge on the current bill date, the function calculates whichfavor policy would have yielded the highest VAT amount applicable to thesingle date charge, had it been applied on the given original bill date.The credit is then accumulated in the accumulator following this policyas if it was applied on the given original bill date.

It will be appreciated that provision is made in anticipation of changesin legislation and user guides would be provided to identify currentacceptable modes of operation.

The fifth function within this object calculates the VAT rate thatapplies to the given VAT exclusive amount, using the given VAT category,charge date and original bill date, following the current favor policy.The function accumulates the VAT exclusive amount in the accumulatortable at the appropriate rate.

The sixth function calculates the VAT rate that applies to the given VATexclusive amount, using the given product code, charge date and originalbill date, following the current favor policy. The function accumulatesthe VAT exclusive amount in the accumulator table at the appropriaterate.

The seventh function calculates the VAT rate that applies to the givenVAT exclusive amount, using the given customer classification, chargedate and original bill date, following the current favor policy. Thefunction accumulates the VAT exclusive amount in the accumulator tableat the appropriate rate.

The eighth function calculates the VAT rate that applies to the givenVAT exclusive amount, using the given combination of product code andcustomer classification, the given charge date and the original billdate. Following the current favor policy, the function accumulates theVAT exclusive amount in the accumulated table at the appropriate rate.

VALIDATE

The VALIDATE object 48 controls operations requested concerning thevalidation of VAT categories, product codes, customer classificationsand combinations of product codes and customer classifications. Nineteenfunctions are available within the object, eight of which are Boolean,in that they produce a true or false response to validation questions.

The first function returns true if a given VAT category exists in theVAT table and a valid VAT rate is assigned to this category on the givendate.

The second function returns true if a given product code exists in theproduct table and a valid VAT category is assigned to this product codeon the given date and a valid VAT rate is associated with this VATcategory in the VAT table on the given date.

The third function returns true if a given customer classificationexists in the customer table and a valid VAT category is assigned tothis customer classification on the given date and a valid VAT rate isassociated with this VAT category in the VAT table on the given date.

A fourth function returns true if the given combination of product codeand customer classification exists in the pair table and a valid VATcategory is assigned to this combination on the given date and a validVAT rate is associated with this VAT category in the VAT table on thegiven date.

A fifth function returns true if the given VAT category is used in theVAT table, and a valid VAT rate applies to it for each date covered bythe period from a given start date to a given end date.

A sixth function returns true if a given product code is used in theproduct table and a valid VAT category applies to this product code foreach date covered by the period from a given period start date to agiven period end date and if all VAT categories that apply to thisproduct code over this period have valid VAT rates associated therewithin the VAT table for each date of the period to which they apply.

A seventh function returns true if a given customer classification isused in the customer table and a valid VAT category applies to thisclassification for each day covered by the period from a given periodstart date up to and including a given period end date and if all VATcategories that apply to this classification over this period have validVAT rates associated therewith in the VAT table for each day of theperiod to which they apply.

An eighth function returns true if the given combination of product codeand customer classification is used in the pair table and a valid VATcategory applies to this combination for each date covered by the periodfrom a given period start date to a given period end date and if all VATcategories that apply to this combination over this period have validVAT rates associated therewith in the VAT table for each day of theperiod to which they apply.

A ninth function returns a VAT rate that applies to a given VAT categoryon the given date according to the VAT table. If the VAT category is notused in the VAT table, appropriate message is returned.

A tenth function returns the VAT category that applies to a givenproduct code on a given date, according to the product table. If theproduct code is not used in the product table or if it is not valid oneach day of the given period, an appropriate message is returned.

An eleventh function returns the VAT category applicable to a givencustomer classification on a given date, according to the customertable. If the classification is not used in the customer table or if itis not valid on each day of the period, an appropriate message isreturned.

A twelfth function returns the VAT category applicable to a givencombination of product code and customer classification on a given date,according to the pair table. If a combination is not used in the pairtable or if it is not valid on each day of the period, an appropriatemessage is returned.

A thirteenth function returns the VAT rate applicable to a given productcode on a given date according to the product table and the VAT table.If the product code is not used in the product table, an appropriatemessage is returned.

A fourteenth function returns the VAT rate applicable to a givencustomer classification on a given date according to the customer tableand the VAT table. If a classification is not used in the customertable, an appropriate message is returned.

Fifteenth function returns the VAT rate applicable to a givencombination of product code and customer classification on a given date,according to the pair table and VAT table. If the combination is notused in the pair table, an appropriate message is returned.

A sixteenth function returns a list of all VAT rates that are applicableto a given VAT category, according to the VAT table on one or more ofthe days of the period from a given start date to a given end date. Ifthe given VAT category is not used in the VAT table, an appropriatemessage is returned.

A seventeenth function returns a list of all VAT categories applicableto a given product code, according to the product table, on one or moreof the days of the period from the given period start date to a givenperiod end date. If a given product code is not used in the producttable, an appropriate message is returned.

An eighteenth function returns a list of all VAT categories applicableto a given customer classification, according to the customer table, onone or more of the days of a period from a period start date to a givenperiod end date. If the given customer classification is not used in thecustomer table, an appropriate message is returned.

A nineteenth function returns a list of all VAT rates that areapplicable to a given combination of product code and customerclassification, according to the pair table, on one or more of the daysof a period from a given period start date to a given period end date.If the given combination is not used in the pair table, an appropriatemessage is returned.

ACCUMULATE

The ACCUMULATE object 50 controls operations requested by billingoperators concerned with resetting and retrieving information frommaintained information items.

A first function resets the accumulator tables.

A second function returns a list of associations that are calculatedfrom the accumulated VAT exclusive amounts and corresponding VAT ratesstored in the accumulator table. The function also returns the VATexclusive amount stored in this table to which VAT applies at zero rateand for which VAT is exempt.

CONFIGURATION MANAGER

The CONFIGURATION MANAGER object 53 controls operations requested byconfiguration operators, concerned with the changing of policies forcalculating VAT charges.

The first function sets the favor policy attribute for accumulatingsingle date charges to a given policy selected from the bill date or thecharge date etc.

A second function returns the current value of the favor policyattribute used when calculating single date charges.

A third function sets a favor policy attribute for the accumulation ofperiod charges to the new given policy, selected from bill date, enddate, or apportion etc.

A fourth function returns the current value of the favor policyattribute for the accumulation of period charges.

A fifth function sets the rounding policy attribute of the ROUNDERobject 52 to a new degree of accuracy. This defines a number of decimalplaces after which truncation takes place, which must be an integervalue between one and six.

The sixth function returns the current value of the rounding policyattribute and the accuracy attribute of the ROUNDER object 52.

CONVERSION FROM THE OBJECT ORIENTED ENVIRONMENT

The procedure for converting the object oriented instructions into aprocedural type language are detailed in FIGS. 15A and 15B.

In the present embodiment, the existing system was originallyconstructed from instructions defined by the COBOL language andinstructions derived from the object oriented definition described aboveare converted into COBOL by initially being converted into instructionsdefined under the information engineering framework licensed by TexasInstruments Inc under the trade mark "IEF". Thus, the terminology usedin the following description is derived from the terminology describedunder IEF, although, it should be appreciated that the underlyingprinciples would be relevant to any suitable procedural type language.

A program constructed under IEF is defined in terms of an activityhierarchy. The procedure is initiated at step 700 and at step 701 theroot function for the activity hierarchy is defined. The lowest levelsof the hierarchy define actual executable programs. However, in thepresent embodiment, translation from the object oriented environmentinto the procedural environment is effected by defining objects in termsof the activity hierarchy. Thus, at step 701 the system name is definedas the root function within the hierarchy. In this embodiment,therefore, the root function would be described as "VAT processor".

A question is asked at step 702 as to whether the objects are typed,that is to say, whether the objects can be grouped together into clearlyidentifiable sets. If this question is answered in the affirmative, asub-function is added to the activity hierarchy identifying theparticular types of functions at 703. Alternatively, if the questionasked at step 702 is answered in the negative, step 703 is bypassed andcontrol is directed to step 704.

In the present example, the functions are typed in terms of internalobjects and external objects wherein, as previously stated, the externalobjects provide interfaces to operators. Thus, in the present example,an internal function is added to the hierarchy at step 703 identifyingthe presence of internal functions and external functions.

Processing now continues by considering each object in turn. At step 704a process is defined having a name equivalent to the object name. Eachobject in the object oriented environment is provided with an objectdescription and this object description is copied to the processdescription at step 705.

In addition to processors being defined under the IEF, it is alsonecessary to define data areas. Thus, at this stage, the underlyingdistinction between procedural instructions and object orientedinstructions becomes visible, in that, separate groupings are made,within the procedural environment, for procedures and data. Theconversion from the object oriented environment into the proceduralenvironment is effected by creating, for each object oriented object, adistinct process and a distinct data area which, when considered as aconnected pair, reflect the definitions provided for that object withinthe object oriented environment.

At step 706 processing is initiated with respect to the data area forthe object being considered. Thus, a subject area is created, for thestorage of data, which is identified by a name derived from the originalobject name.

At step 707 a similar step is performed for the subject area which wasperformed for the process at step 705. Thus, the object description,defining its state, is copied to the subject area description.

Thus, on the termination of step 707, a process area and a data area hasbeen defined for the instruction specified within the particular object.

Each object is itself defined, within the object oriented environment interms of attributes 708 and it is now necessary to reflect theseattributes within the object process of the procedural environment.

The attributes of the object oriented objects are defined within the IEFenvironment in terms of entities and, in accordance with IEF protocols,entities also have collections of attributes. In order to distinguishbetween an object oriented Attribute and a IEF attribute, objectsoriented Attributes will be specified with an A.

At step 709 the Attributes description is copied to the entitydescription. At step 710 entity attributes are defined for each dataitem in the object Attribute.

An example may be considered as follows. In the object orientedenvironment an Attribute may specify the address of a customer. Thisaddress is translated into an entity within the procedural IEFenvironment and each attribute within this environment will specify anitem of data, such as a single line of that address.

Within the IEF environment, entities and attributes are placed in datatables and in order to effect the transfer of information to and fromthe table, it is necessary to specify a key, that is to say, arelationship with a particular portion of the data entry and theparticular location within the data table. Thus, at step 711 a key isdefined for the data entity, along with volumetric informationspecifying the size of the entity within the database.

Thus, it will be appreciated that step 710 will create a number ofattributes which are considered in turn at step 712. At step 712 datatypes are defined for each of these attributes and ranges of validvalues are also specified. Thus, a question is asked at step 713 as towhether another entity attribute is present and if this question isanswered in the affirmative, control is returned to step 712, whereuponthe next attribute is considered.

If the question asked at step 713 is answered in the negative, aquestion is asked at step 714 as to whether another object Attribute isto be processed. If this question is answered in the affirmative,control is returned to step 708, whereupon a further entity is definedand attributes are specified within this entity.

Eventually, all of the object Attributes will have been considered andthe question asked at step 714 will be answered in the negative,resulting in control being directed to step 715. After all of the objectattributes have been considered for the particular object, resulting inprovision being made for them within the procedural environment, theprocessing code is now transferred by creating an elementary process atstep 715, given a name reflecting the name of its originating object andthe particular operation under consideration.

At step 716 the operation description is copied to the processdescription and at step 717 imports and exports are defined, in terms ofthe nature of data transferred between particular objects.

At step 718 a definition is made of the expected effects, to the effectas to whether data is created deleted or transferred thereafter, aquestion is asked at step 719 as to whether another object operation ispresent and if this question is answered in the affirmative, control isreturned to step 715. Eventually, the question asked at step 719 will beanswered in the negative, resulting in control being directed to step720.

The generation of code within the IEF environment will result in acreate-read-update-delete (CRUD) matrix being created and this matrixprovides the basis for ensuring that the encapsulation of the objectsoriented environment has successfully been reflected in the proceduralenvironment.

Within an object oriented environment, encapsulation refers to thestructure by which objects are defined effectively in isolation,encapsulated, as separate recognisable entities. This encapsulation isreflected within the procedural environment, by ensuring thatinteractions between object-derived portions of the procedural code mayonly interact in the way specified by the encapsulation of the objectoriented environment. Thus, at step 720 a question is asked as towhether there is any encapsulation violation and if this question isanswered in the affirmative, the expected effects are re-defined at 721so as to ensure correct encapsulation as defined within the objectoriented environment. Alternatively, if the question asked at step 720is answered in the negative, control is directed to step 722.

Thus, after the definitions for each of the objects, in terms of theirrespective process are and data area, has successfully been encapsulatedwithin the procedural environment, operations within the object havebeen successfully translated. It is now necessary to specify theinteractions between objects, therefore at step 722 object collaborationis specified in terms of entries made into the IEF structure chart.

At step 723 the operations performed by each object are translated intoan algorithm compatible with the action diagram of the IEF environment.

A question is asked at step 724 as to whether other operations are used,that is to say, whether other objects are called by the particularobject under consideration. If the question is answered in theaffirmative, a match is made of inputs and outputs between the twoobjects at step 725. Alternatively, if the question asked at step 724 isanswered in the negative, control is directed to step 726.

At step 726 the question is asked as to whether the object underconsideration is an interface object. If this question is answered inthe affirmative, the exit state within the IEF environment is set to"processing started" at the start of the action block. Alternatively, ifthe question asked at step 726 is answered in the negative, control isdirected to step 728, whereupon the exit state is set to "processing OK"before the end of the action block.

After processing performed at step 727 or at step 728, the object fromthe object oriented environment has been fully translated within theprocedural environment of the IEF and control is therefore directed tostep 729.

At step 729 a question is asked as to whether another object from theobject oriented environment is to be translated into the proceduralenvironment and if answered in the affirmative, control is returned tostep 704. Eventually, all of the objects will have been translated,resulting in the question being asked at step 729 being answered in thenegative, whereupon the process terminates at step 730.

It should be noted that, by employing a conversion procedure such asthat set out above, an object oriented environment can be used toconfigure and modify a data processing system which is otherwise builtin a procedural environment. Hence an aspect of the present invention isthe provision of a configuration system, for use in a billing andcharging environment incorporating procedural based data processing,comprising parts i) to iv) set out above in the summary of theinvention.

What is claimed is:
 1. A process for generating billable amounts inrespect of data records for the supply of goods or services over aperiod of time, said process comprising:a period charge interfaceobject, which provides control functionality for use by the process inrelation to charges incurred over a period of time; a tax table object,defining tax rates and callable by said period charge interface object;a tax calculation object for calculating tax values in respect of saidsupply of goods or services, callable by the period charge interfaceobject; an accumulation object, for accumulating values returned to theperiod charge object from the tax calculation object, wherein, in use,input data including a period start date and a period end date aresupplied to the period charge interface object, tax rates are suppliedto the period charge interface object from the tax table object, a taxcalculation is made by the tax calculation object, and the resultingcalculated tax values are supplied to the accumulation object; andwherein a "table manager" object is arranged to supply values to the taxtable object and to select operational policy options.
 2. A processaccording to claim 1, wherein the calculation of tax at the bill date isa selectable option.
 3. A process according to claim 1, wherein thecalculation of tax at the end of the usage date is a selectable option.4. A process according to claim 1, wherein the apportionment of tax overthe usage period is a selectable option.
 5. A process according to claim1, including a "single date charge" object for calculating tax for atransaction occurring at a specific date, wherein said single datecharge object is arranged to call the tax table object and theaccumulation object.
 6. A process according to claim 1, including a "taxrefund" object arranged to call said tax calculation object, the periodcharge object and a re-tax object.
 7. A process according to claim 1,wherein a "rounder" object callable by said tax calculation object isarranged to round values calculated by said tax calculation object.
 8. Aprocess according to claim 7, wherein a "configuration" object isarranged to facilitate programming of said rounder object.
 9. Apparatusfor processing data representing a supply of goods or services over aperiod of time to calculate tax associated with said supply, comprisingprocessing means facilitating execution within an object orientatedenvironment, characterised by the provision of:a "period charge"interface object; a "tax table" object defining tax rates and callableby the period charge interface object; a tax calculation object forcalculating tax for individual items, callable by the period chargeinterface object; and an "accumulation" object for accumulating valuesreturned to the period charge object from said tax calculation object,wherein input data including a period start date and a period end dateare supplied to the period charge interface object, tax rates aresupplied to the period charge object from the tax table object, the taxcalculation is made by the tax calculation object, and calculated taxvalue is supplied to the accumulation object.
 10. A method of convertingprograms developed under an object oriented environment intoinstructions implementable by a procedurally based processing device,said method comprising:(a) creating an activity hierarchy of functionsfor each of said objects; (b) creating a data subject area for each ofsaid objects; and (c) defining a matrix of processes against dataentities resulting from steps (a) and (b) arranged to specify therelationship between object derived programs and object derived datasubject areas to thereby retain encapsulation as defined by an objectoriented program.
 11. A method according to claim 10, wherein said stepof creating a data area includes defining a process for each object. 12.A method according to claim 10, wherein said data area creation stepincludes copying object descriptions to respective process descriptions.13. A method according to claim 10, wherein said step of creating aprocedural program includes creating an elementary process derived froman object and from an operation.
 14. A method according to claim 10,wherein said activity hierarchy creation step includes defining importand export values.
 15. A method according to claim 10, including checksfor encapsulation violation.
 16. A method of calculating taxes definedin an object oriented environment and converted into a proceduralprogram by a method according to claim
 10. 17. A method according toclaim 16, wherein said object oriented definition includes:a "periodcharge" interface object; a "tax table" object defining tax rates andcallable by said period charge interface object; a tax calculationobject for calculating tax for individual items, callable by the periodcharge interface object; and an "accumulation" object for accumulatingvalues returned to the period charge object from said tax calculationobject, wherein input data including a period start date and a periodend date are supplied to the period charge interface object, tax ratesare supplied to the period charge object from the tax table object, atax calculation is made by the tax calculation object, and thecalculated tax value is supplied to the accumulation object.
 18. Aprocess according to claim 17, wherein a "rounder" object callable bysaid tax calculation object, is arranged to round values calculated bysaid tax calculation object.
 19. A process according to claim 17,wherein a "configuration" object is arranged to facilitate programmingof said rounder object.
 20. A data processing system, for use in pricingand charging equipment, to process data relevant to a period of time byselecting and applying appropriately one or more date-related modifyingfactors, the system comprising:i) a data input for the data, said dataa)relating to one or more chargeable event(s), b) containing for eachchargeable event at least one charge-related value, as duration, and atleast one event date, and c) wherein, for at least one chargeable event,an event date comprises a start date and an end date relating to aperiod of time; ii) a process control module for controlling processingof said data; iii) a first data store for holding at least one set ofdefinitions, each definition comprising, directly or indirectly, atleast one of said modifying factors and at least one definitionincluding one or more dates of validity relating to a modifying factor;iv) a second data store arranged in sections for allocation torespective modifying factors; v) means for determining a relevantidentifier for each charge-related value; and vi) calculating means forcalculating a set of charge values from said charge-related valuestogether with price data wherein the process control module is arranged,on receipt of the data at the input, to control the system such thatit:vii) determines a relevant identifier for each charge-related valuefrom the data; viii) accesses the first data store and locates therelevant definition or definitions for that identifier; ix) calculates aset of charge values from said charge-related values together with pricedata; x) sorts the charge values according to modifying factor, usingthe relevant definition; and xi) outputs the charge values to therelevant sections of the second data store, the charge value for anychargeable event for which the event date comprises a start date and anend date being apportioned between sections in accordance with any dateof validity included in a relevant definition.
 21. A system as in claim20 wherein the modifying factor for a section of the second data storeis zero.
 22. A system as in claim 20 wherein the first data store holdsa plurality of sets of definitions, the identifiers for each of thedefinitions being unique.
 23. A system as in claim 20 wherein the datacontains, for each chargeable event, an identifier for a definition. 24.A system as in claim 20 wherein the means for determining a relevantidentifier comprises means for identifying category codes contained bythe data in relation to the chargeable events, and for identifyingpredetermined combinations of category codes in relation to a chargeableevent, each such combination of category codes determining a differentidentifier in place of the identifiers otherwise determined by each ofthe category codes on its own.
 25. A system as in claim 20 which furthercomprises means to input one or more new definitions to said first datastore.
 26. A system as in claim 20 which further comprises means forsubstituting, at step x), a different date for a date of validity from adefinition, and for repeating steps vii) to xi) in respect of datapreviously processed by the system.
 27. A system as in claim 20 whichfurther comprises means for updating one or more definitions in thefirst data store and for reprocessing data, by use of the system, usingthe updated definitions.
 28. Apparatus for use in a system as in claim20 for processing data representing a supply of goods or services over aperiod of time to calculate tax associated with said supply, theapparatus comprising processing means facilitating execution within anobject orientated environment, characterized by the provision of:a"period charge" interface object; a "tax table" object defining taxrates and callable by the period charge interface object; a taxcalculation object for calculating tax for individual items, callable bythe period charge interface object; and an "accumulation" object foraccumulating values returned to the period charge object from said taxcalculation object, wherein input data including a period start date anda period end date are supplied to the period charge interface object,tax rates are supplied to the period charge object form the tax tableobject, the tax calculation is made by the tax calculation object, andcalculated tax value is supplied to the accumulation object.
 29. Aprocess for generating billable amounts in respect of data records forthe supply of goods or services over a period of time, by use of asystem according to claim 20, the process being characterized by:aperiod charge interface object, which provides control functionality foruse by the process in relation to charges incurred over a period oftime; a tax table object, defining tax rates and callable by said periodcharge interface object; a tax calculation object for calculating taxvalues in respect of said supply of goods or services, callable by theperiod charge interface object; and an accumulation object, foraccumulating values returned to the period charge object from the taxcalculation object, wherein, in use, input data including a period startdate and a period end date are supplied to the period charge interfaceobject, tax rates are supplied to the period charge interface objectfrom the tax table object, a tax calculation is made by the taxcalculation object, and the resulting calculated tax values are suppliedto the accumulation object.
 30. A process as in claim 29 including a"tax refund" object arranged to call said tax calculation object, theperiod charge object and a re-tax object.
 31. A process as in claim 29wherein a "rounder" object callable by said tax calculation object isarranged to round values calculated by said tax calculation object. 32.A process as in claim 31 wherein a "configuration" object is arranged tofacilitate programming of said rounder object.
 33. A process as in claim29 wherein a "table manager" object is arranged to supply values to thetax table object and to select operational policy options.
 34. A processas in claim 33 wherein the calculation of tax at the bill date is aselectable option.
 35. A process as in claim 33 wherein the calculationof tax at the end of the usage date is a selectable option.
 36. Aprocess as in claim 33 wherein the apportionment of tax over the usageperiod is a selectable option.
 37. A process as in claim 29 including a"single date charge" object for calculating tax for a transactionoccurring at a specific date, wherein said single date charge object isarranged to call the tax table object and the accumulation object.
 38. Aconfiguration management system, for use in configuring pricing andcharging equipment for processing data which has an associated set ofmodifying factors, by selecting and applying appropriately one or moreof said modifying factors, the configuration management system includinga data processing system for use in pricing and charging equipment, toprocess data relevant to a period of time by selecting and applyingappropriately one or more date-related modifying factors, the dataprocessing system comprising:i) a data input for the data, said dataa)relating to one or more chargeable event(s), b) containing for eachchargeable event at least one charge-related value, as duration, and atleast one event date, and c) wherein, for at least one chargeable event,an event date comprises a start date and an end date relating to aperiod of time; ii) a process control module for controlling processingof said data; iii) a first data store for holding at least one set ofdefinitions, each definition comprising, directly or indirectly, atleast one of said modifying factors and at least one definitionincluding one or more dates of validity relating to a modifying factor;iv) a second data store arranged in sections for allocation torespective modifying factors; v) means for determining a relevantidentifier for each charge-related value; and vi) calculating means forcalculating a set of charge values from said charge-related valuestogether with price data wherein the process control module is arranged,on receipt of the data at the input, to control the system such thatit:vii) determines a relevant identifier for each charge-related valuefrom the data; viii) accesses the first data store and locates therelevant definition or definitions for identifier; ix) calculates a setof charge values from said charge-related values together with pricedata; x) sorts the charge values according to modifying factor, usingthe relevant definition; and xi) outputs the charge values to therelevant sections of the second data store, the charge value for anychargeable event for which the event date comprises a start date and anend date being apportioned between sections in accordance with any dateof validity included in a relevant definition.
 39. A process for use inpricing and charging event-related data relevant to a period of time,the data having been output by a communications system, said processcomprising:i) determining a relevant identifier for each charge-relatedvalue from the data; ii) accessing a first data store and locating arelevant definition or definitions for that identifier; iii) calculatinga set of charge values from said charge-related values together withprice data; iv) sorting the charge values according to modifying factor,using the relevant definition; and outputting the charge values torelevant sections of a second date store; wherein the charge value forany chargeable event for which the event date comprises a start date andan end date being apportioned between sections of the second data storein accordance with any date of validity included in a relevantdefinition.